1. Field of the Invention
This invention relates in general to the fields of Computer Operating Systems, Multi-processor Hardware Systems, Object Oriented Programming, and Virtual Memory Systems. In particular, the invention relates to improved techniques for establishing and efficiently handling relationships between a client program, a file system server and a virtual memory manager ("VMM").
2. Background
Object oriented operating systems, with microkernels which permit client level implementation of file systems, create complexities in memory management which clients have not had to deal with in the past. Moreover, on widely distributed computer networks, having files resident on different computers, clients are not prepared to handle the fact that file accesses may produce unnecessary network communications traffic.
This disclosure describes some of these inefficiencies that exist in the prior art and provides a method and apparatus for significantly reducing them.
The role of the operating system in a computer has traditionally been to efficiently manage the hardware resources (the central processing unit ("CPU"), memory and input/output devices). This management function has included the role of managing the file system, which comprises data and programs stored generally on a disk drive or magnetic tape system. In modern systems, this management function has included the use of a virtual memory subsystem. More specifically, the operating system has traditionally been responsible for: creating and deleting files and directories; providing support for primitive program routines for manipulating files and directories; mapping files onto disk storage; and general protection of the files by limiting access of programs, processes and users to the files.
Distributed computer systems, some with shared memory, and some with remotely accessible file systems, have led to the creation of "distributed file systems ("DFS")" to support the sharing of files by multiple users when the files are physically dispersed among the various computers of a distributed system. A DFS is a file system whose clients, servers and storage devices are dispersed among the machines of a distributed system. The location and multiplicity of the servers and storage devices is transparent to the client.
In a DFS the time to satisfy a client's request is a function of: disk access time and a small amount of associated CPU time; the time needed to deliver the request to a server; the time for getting the response back across the network to the client; the actual data transfer time; and the related CPU overhead for running the communications protocol software. Access times for DFSs have been shortened by the use of caching techniques on local machines to minimize the overall remote file accessing times. Nevertheless, minimization of the access times for retrieval of data from remote files remains a major goal of computer hardware and software designers. For additional information on operating systems, file systems and related problems, see the text "Operating System Concepts" 3rd edition, by A. Silberschatz, J. Peterson and P. Glavin, 1991 Addison-Wesley Publishing Inc.
With the advent of microkernel operating systems, file systems are being implemented outside of the kernel in user level servers. These new file systems must solve a new set of problems to provide efficient performance. For example, the following describes a number of areas where caching of file data and file attributes would provide significant efficiency improvements in either memory usage or in network accesses in such user level file system implementations.
The MACH operating system developed by Carnegie Mellon University, is an object oriented operating system, with a minimum sized extensible kernel, based upon communications facilities. All requests to the kernel, and all data movement among processes are handled through one communications mechanism. In MACH, many traditionally kernel-based functions, such as file services, can be implemented as user-level servers. Other modern operating systems like MACH are being developed.
MACH presently implements virtual memory techniques in an object oriented system. In MACH, the use of a memory object to both encapsulate the mapping and attributes of a memory space and to control the communications to a memory cache object and the related paging operations can result in an inefficient use of the physical memory space used by the cache as well as related unnecessary paging operations where two or more programs or tasks or processes or threads (hereinafter "programs") with each having access rights, are using the same memory space. These inefficiencies result from the fact that MACH creates a separate related memory cache object each time a new memory object with different access rights is mapped, without regard for the possibility that the same data is already being paged by another memory object-memory cache object pair. For example, if a client wishes to access a file, the client sets up a file system object and memory maps it, MACH creates a memory object and related cache and communications port to accept messages for the memory object to get data from and write data to the file. If a second client with a different access mode, wishes to access the same file, MACH sets up a second memory object, related data cache and communications port. This is obviously a redundant and inefficient use of scarce memory resources as well as a duplication of the system overhead when the file is located on a remote machine. For more detailed information on MACH, see "Exporting a User Interface to Memory Management from a Communications-Oriented Operating System" by Michael Wayne Young, Doctoral Thesis for Carnegie Mellon University, November 1989, CMU-CS-89-202.
In the prior art, an additional problem exists with file objects besides the fact that a duplicate MACH memory object with a duplicate cache is set up if a second user with a different access mode, memory-maps the same file object. This is the problem created by the fact that all requests on the file object go the same location; that is, to the location containing the implementor of the file object. Going to the same location for all requests is inefficient when the file data resides on a remote host. This is especially true when two client programs wish to access the same file and at least one of them wishes to access the file attributes. For example, there are two possible ways to approach this problem but each has its performance problems:
Case 1) Implementor of the file is on a remote machine. Referring to FIG. 1, a first client 12 and a second client 14 are on local node 10 as is a VMM 16. Remote node 24 contains a file server 26 with a file object 28 and a connected file storage system 25. The first client 12 has mapped the file object 28 using the VMM 16 to access file data through the memory object port 18 to cache object 30 connection. The second client 14 wishes to access the same file but wants to "query/set attributes". Since the VMM 16 cannot cache this data, the second client 14 must access the remote file object 28 directly without the benefit of caching. In this case all requests to the file are remote. Whereas this may not be a problem for page-in/page-out requests from the VMM 16 for the first client 12 (because the VMM can cache the data locally), all read/write requests as well as attribute query/set requests by the second client 14 must also go to the remote implementor of the file with no possibility of caching the data or attributes. Note that the file data requested by the second client's direct request may even be already located in the cache controlled by the local VMM 16 but there is no way to know this or to share this information.
Obviously it would be more efficient if both clients could access a common cache locally, both in terms of memory usage and in reduced network accesses. Moreover, if the attributes could also be cached locally, even more network accesses would be saved.
Case 2) Implementor of the file is on the local machine, but the data is on a remote machine. Referring now to FIG. 2, again local node 10 contains the first client 12, and the second client 14, and the VMM 16. But in this case the local node also contains a file server 40 which contains the file object 44 for file 46 located on the remote node 24. The first client 12 invokes its data read/write requests to the file object 44 on the same node 10. The second client 14 invokes commands on the file object 44 as well. The file object 44, the implementor of the file, has the ability to cache file data and attributes so it could satisfy any requests from its local cache. However, all page-in/page-out operations by the VMM 16 bear an added cost of going indirectly through the local implementor (the file object 44) to the remote node 24 that holds the data, instead of going directly to the remote node 24 for the data.
Access time could be saved if the VMM could access the remote file directly, and could cache the data and attributes for all local clients that wanted access to the file.
Other kinds of file operations that would benefit from caching include:
Mapping. Each time that a client domain maps a file into its address space, a bind call must go to the file server. If the file is remote, this requires a network access on each map call. If the result of binds could be cached locally, then many of these network accesses could be eliminated. PA1 Getting file attributes. If the file is remote, several opportunities for saving network accesses are available by caching the file length. In addition, all of a file's attributes are returned via the stat call. In current UNIX.RTM. system, stat calls are very frequent. This is yet another area where caching can be effective. (UNIX is a registered trademark of UNIX Systems Laboratories Inc.).
Obviously if the implementor, client file server and the file system are all on the same machine, there is no network overhead involved, although the inefficiencies of possibly duplicated data storage remains. However, cases 1 and 2 are the more common in a DFS. These problems create unnecessary network traffic and redundant use of memory for multiple caching of the same data.